The STREAMS framework (i.e., “STREAMS”) has become an industry de facto framework for implementing data communication network protocols, as well as various types of device drivers. The STREAMS provides a bidirectional data path between a user level process, such as an application program, and a device driver in the kernel. A typical STREAMS data path (i.e., “stream” or “STREAMS stack”) includes three main types of processing elements: a stream head, optional processing modules, and the device driver. A “STREAMS stack” is a stack of those processing elements (i.e., a stack of STREAMS modules).
The device driver is typically found at the end, or bottom of the STREAMS stack. Drivers can be added to the kernel by linking their object files with the kernel object files. The STREAMS framework includes a set of routines that provide an interface between the user process level (known as “user space”) and the kernel level (known as “kernel space”), and it also includes a set of routines that provide an interface between kernel modules (i.e., “STREAMS modules”).
A stack of STREAMS modules (i.e. STREAMS stack) provides a bidirectional data path between a process at the user space and a device driver in the kernel space. Data written by a user process travels downstream toward the device driver, and data received by the device driver from the hardware space travels upstream to be retrieved by the user process.
The fundamental building block in STREAMS is the queue (i.e., “STREAMS QUEUE”). The queue links one module to the next module, thereby forming a stack of STREAMS modules, as discussed in, for example, commonly-assigned U.S. Pat. No. 5,815,707. Each module in a STREAMS stack contains one pair of queues (i.e., one queue for the read side (upstream) and one queue for the write side (downstream)). The queue serves as a location to store messages as they flow up and down the STREAMS stack, contains status information, and acts as a registry for the routines that are used to process messages. Additional details on the STREAMS framework are also found, for example, in “UNIX SYSTEM V NETWORK PROGRAMMING”, by Stephen A. Rago, Addison Wesley Professional Computing Series (1993), and in “STREAMS/UX for HP 9000 Reference Manual” which is available from HEWLETT-PACKARD COMPANY.
However, the current STREAMS framework does not have the capability to pass the metadata of the data that is being passed between modules in the STREAMS stack. The metadata contains the attributes or ancillary information of the data. As an example, in a typical STREAMS stack that implements a TCP/IP communication, the STREAMS stack will have modules that will not use the same data format. Specifically, this TCP/IP STREAMS stack will have upper layers that use the Transport Provider Interface (TPI) data format, and will have lower layers that use Data Link Provider Interface (DLPI) data format. Currently there is no way to pass the metadata independent of data formats. Therefore, the current technology is not able to pass metadata within the STREAMS framework independent of the data format that is used for the data. Therefore, the current technology is subjected to at least the above constraints and deficiencies.